32장. AI가 외부 도구를 사용한다는 것

앞 장에서는 AI를 개발 프로세스에 넣는 방법을 살펴보았다.

Jira 이슈 초안 생성, GitHub PR 요약, 릴리즈 노트 작성, 장애 리포트 초안 생성, 회의록 액션 아이템 추출, 주간 업무 보고 자동화 같은 업무에 AI를 활용할 수 있다고 했다.

중요한 점은 AI가 모든 것을 자동으로 결정하게 만드는 것이 아니라, 사람이 판단하기 쉽게 초안을 만들고 정리하게 하는 것이라고 했다.

이번 장부터는 조금 더 발전된 주제로 넘어간다.

바로 AI가 외부 도구를 사용한다는 것이다.

지금까지의 AI 활용은 대부분 대화 중심이었다.

개발자가 질문한다.
AI가 답변한다.
개발자가 답변을 보고 직접 실행한다.

예를 들어 이런 방식이다.

개발자:
이 로그를 보고 장애 원인 후보를 정리해줘.

AI:
원인 후보는 3가지입니다.
1. DB 연결 지연
2. 외부 API timeout
3. 최근 배포된 캐시 키 변경

이 방식에서 AI는 답변만 한다.
실제로 DB를 조회하거나, Jira 이슈를 만들거나, GitHub PR에 댓글을 쓰지는 않는다.

그런데 AI가 외부 도구를 사용할 수 있게 되면 흐름이 달라진다.

AI가 문서를 검색할 수 있다.
AI가 Jira 이슈를 조회할 수 있다.
AI가 GitHub PR 목록을 읽을 수 있다.
AI가 사내 API를 호출할 수 있다.
AI가 DB 조회 결과를 바탕으로 답변할 수도 있다.

이때 AI는 단순한 챗봇이 아니라, 여러 도구를 연결해서 작업을 수행하는 실행 보조자가 된다.

이번 장에서는 AI가 외부 도구를 사용한다는 것이 무엇인지, 단순 챗봇과 무엇이 다른지, 읽기 작업과 쓰기 작업을 왜 구분해야 하는지, 사람 승인 단계가 왜 필요한지 살펴본다.

그리고 다음 장에서 다룰 MCP를 이해하기 위한 기본 개념을 정리한다.

1. 단순 챗봇과 도구 사용 AI의 차이

단순 챗봇은 사용자의 질문에 답변하는 구조다.

사용자가 질문을 입력하면 AI는 자신이 알고 있는 지식이나 사용자가 제공한 문맥을 바탕으로 답변한다.

예를 들어 다음과 같다.

사용자:
우리 서비스에서 장애 리포트에 들어가야 할 항목을 정리해줘.

AI:
장애 리포트에는 발생 시간, 종료 시간, 영향 범위, 원인, 조치 내용, 재발 방지 대책이 들어가야 합니다.

이 경우 AI는 답변만 한다.

실제 장애 로그를 조회하지 않는다.
모니터링 시스템에 들어가지 않는다.
Jira 이슈를 생성하지 않는다.
Slack 대화를 읽지 않는다.

반면 도구 사용 AI는 외부 시스템과 연결될 수 있다.

예를 들어 다음과 같은 흐름이 가능하다.

사용자:
어제 발생한 로그인 장애 내용을 바탕으로 장애 리포트 초안을 만들어줘.

AI:
1. 모니터링 알림 기록 조회
2. 관련 Slack 장애 대응 스레드 조회
3. 최근 배포된 GitHub PR 확인
4. Jira 장애 이슈 확인
5. 장애 리포트 초안 작성

이 경우 AI는 단순히 답변만 하는 것이 아니다.
외부 도구를 사용해서 필요한 정보를 가져오고, 그 결과를 바탕으로 답변한다.

차이를 간단히 정리하면 다음과 같다.

도구 사용 AI는 더 강력하다.

하지만 강력하다는 것은 더 위험할 수도 있다는 뜻이다.

단순 챗봇이 잘못 답하면 사용자가 확인하고 무시할 수 있다.
하지만 도구 사용 AI가 잘못된 API를 호출하거나, 잘못된 Jira 이슈를 생성하거나, 잘못된 DB 변경을 실행하면 실제 시스템에 영향이 생길 수 있다.

그래서 AI가 외부 도구를 사용할 때는 권한과 승인 구조가 중요하다.

2. AI가 외부 도구를 사용한다는 것

AI가 외부 도구를 사용한다는 것은 AI가 단순히 말만 하는 것이 아니라, 특정 기능을 호출할 수 있다는 뜻이다.

여기서 외부 도구는 다양하다.

- 파일 검색
- 문서 조회
- DB 조회
- REST API 호출
- Jira 이슈 조회
- GitHub PR 조회
- Slack 메시지 검색
- 캘린더 조회
- 이메일 검색
- 배포 시스템 조회
- 모니터링 지표 조회

예를 들어 AI에게 다음과 같이 요청할 수 있다.

최근 7일 동안 로그인 관련 장애 이슈를 찾아서 요약해줘.

도구가 없는 AI는 사용자가 제공한 정보만으로 답해야 한다.
하지만 도구가 연결된 AI는 Jira나 장애 관리 시스템에서 로그인 관련 이슈를 검색할 수 있다.

또 다른 예를 보자.

이번 주에 병합된 PR 중 정산 관련 변경 사항을 정리해줘.

도구가 없는 AI는 알 수 없다.
사용자가 PR 목록을 직접 붙여넣어야 한다.

도구가 연결된 AI는 GitHub에서 이번 주 병합된 PR을 조회하고, 제목과 diff를 분석해서 정리할 수 있다.

이처럼 외부 도구 연결은 AI의 범위를 넓혀준다.

기존에는 AI가 “사용자가 준 정보”를 바탕으로 답했다면, 이제는 AI가 “필요한 정보를 찾아와서” 답할 수 있다.

다만 이 구조에서는 반드시 질문해야 한다.

AI가 어떤 도구를 사용할 수 있는가?

AI가 어떤 데이터에 접근할 수 있는가?

AI가 읽기만 할 수 있는가, 쓰기도 할 수 있는가?

사용자가 볼 수 없는 데이터까지 AI가 볼 수 있는가?

도구 호출 기록은 남는가?

위험한 작업은 승인 후 실행되는가?

AI가 외부 도구를 사용하는 순간, AI는 단순 답변 시스템이 아니라 권한이 필요한 시스템이 된다.

3. Tool Calling 다시 보기

AI가 외부 도구를 사용하는 방식 중 하나가 Tool Calling이다.

Tool Calling은 말 그대로 AI가 필요한 도구를 호출하는 구조다.

예를 들어 AI에게 계산 도구, 검색 도구, DB 조회 도구, Jira 조회 도구가 연결되어 있다고 해보자.

사용자가 질문한다.

지난주 완료된 Jira 이슈 중 배포가 필요한 항목을 정리해줘.

AI는 이 질문을 보고 먼저 어떤 도구가 필요한지 판단한다.

필요한 도구:
- Jira 이슈 검색 도구
- 이슈 상세 조회 도구
- 배포 라벨 확인 도구

그다음 도구를 호출한다.

Jira 검색:
기간 = 지난주
상태 = 완료
프로젝트 = 개발팀

도구 호출 결과를 받으면 AI는 그 결과를 다시 읽고 정리한다.

완료된 이슈 12건 중 배포 필요 라벨이 있는 항목은 4건입니다.  
그중 2건은 API 변경이 포함되어 운영팀 공유가 필요합니다.

이것이 Tool Calling의 기본 흐름이다.

사용자 요청
→ AI가 필요한 도구 판단
→ 도구 호출
→ 결과 수신
→ AI가 결과 해석
→ 사용자에게 답변

Tool Calling에서 중요한 점은 AI가 직접 모든 것을 알고 있는 것이 아니라는 것이다.

AI는 어떤 도구를 호출할지 판단하고, 도구가 반환한 결과를 해석한다.

예를 들어 AI가 DB의 최신 데이터를 알고 있는 것이 아니다.
DB 조회 도구를 호출해서 그 시점의 데이터를 가져오는 것이다.

이 구조는 강력하지만, 다음 문제가 생길 수 있다.

- AI가 잘못된 도구를 선택할 수 있다
- 잘못된 파라미터로 도구를 호출할 수 있다
- 도구 결과를 잘못 해석할 수 있다
- 권한이 없는 데이터를 조회할 수 있다
- 쓰기 도구를 잘못 호출할 수 있다

그래서 Tool Calling을 설계할 때는 도구 자체의 안전장치가 필요하다.

AI가 잘못 요청하더라도 도구가 위험한 작업을 막아야 한다.

Tool Calling이란?
AI가 답변을 만들기 위해 외부 기능을 호출하는 구조다.
예를 들어 검색, DB 조회, API 호출, 파일 읽기 같은 도구를 AI가 필요에 따라 사용한다.

4. 읽기 작업과 쓰기 작업의 차이

AI가 외부 도구를 사용할 때 가장 먼저 나눠야 하는 것이 있다.

바로 읽기 작업과 쓰기 작업이다.

읽기 작업은 데이터를 조회하는 것이다.

- 문서 검색
- Jira 이슈 조회
- GitHub PR 조회
- DB SELECT
- 로그 조회
- 모니터링 지표 조회
- 캘린더 일정 조회

쓰기 작업은 데이터를 변경하는 것이다.

- Jira 이슈 생성
- GitHub PR 댓글 작성
- DB INSERT, UPDATE, DELETE
- 배포 실행
- 권한 변경
- 이메일 발송
- Slack 메시지 전송
- 외부 API로 상태 변경

읽기와 쓰기는 위험도가 다르다.

읽기 작업도 보안상 중요하다.
권한이 없는 데이터를 읽으면 정보 유출이 된다.

하지만 쓰기 작업은 더 위험하다.
잘못 실행되면 시스템 상태가 바뀐다.

예를 들어 AI가 Jira 이슈를 잘못 조회하는 것과, 잘못된 Jira 이슈를 100개 생성하는 것은 위험도가 다르다.

AI가 DB에서 사용자 정보를 조회하는 것도 조심해야 하지만, AI가 DB에서 사용자 상태를 변경하는 것은 훨씬 더 조심해야 한다.

따라서 도구를 설계할 때는 읽기와 쓰기를 분리해야 한다.

처음 AI 도구를 연결할 때는 읽기부터 시작하는 것이 좋다.

예를 들어 다음 작업은 비교적 안전하게 시작할 수 있다.

- 문서 검색
- PR 요약
- Jira 이슈 조회
- 회의록 요약
- 로그 검색 결과 요약

쓰기 작업은 충분히 검증한 뒤 도입해야 한다.

그리고 쓰기 작업에는 승인 구조가 있어야 한다.

AI:
다음 Jira 이슈를 생성하려고 합니다.

제목:
관리자 검색 성능 개선 검토

설명:
...

생성하시겠습니까?

사용자:
승인

시스템:
Jira 이슈 생성

이 흐름에서 AI는 초안을 만들고, 사람은 승인한다.

AI가 바로 실행하지 않는 것이 중요하다.

5. 외부 도구 연결 시 필요한 권한

AI가 외부 도구를 사용하려면 권한이 필요하다.

사람이 Jira에 접근하려면 계정과 권한이 필요하듯이, AI도 도구에 접근하려면 권한이 필요하다.

문제는 AI에게 권한을 너무 넓게 주면 위험하다는 점이다.

예를 들어 AI에게 모든 Jira 프로젝트 읽기 권한을 주면, 사용자가 보지 못해야 할 이슈까지 AI가 읽을 수 있다.

AI에게 모든 GitHub 저장소 접근 권한을 주면, 현재 작업과 관계없는 민감한 저장소까지 접근할 수 있다.

AI에게 운영 DB 조회 권한을 주면, 개인정보나 민감한 데이터가 노출될 수 있다.

따라서 권한은 최소 권한 원칙을 따라야 한다.

최소 권한 원칙이란?
어떤 사용자나 시스템이 작업을 수행하는 데 필요한 최소한의 권한만 부여하는 원칙이다.
AI 도구도 필요한 범위보다 넓은 권한을 가지면 안 된다.

예를 들어 문서 검색 AI라면 모든 문서를 읽을 필요가 없다.

사용자가 접근할 수 있는 문서만 읽어야 한다.

Jira 요약 AI라면 모든 프로젝트를 볼 필요가 없다.
해당 팀 프로젝트만 읽으면 된다.

DB 조회 AI라면 운영 DB 원본에 직접 연결하기보다, 읽기 전용 복제 DB나 제한된 뷰를 사용하는 것이 좋다.

권한 설계 시 확인할 질문은 다음과 같다.

- 이 AI는 어떤 시스템에 접근해야 하는가
- 읽기 권한만 필요한가
- 쓰기 권한이 필요한가
- 사용자별 권한을 반영하는가
- AI가 관리자 권한으로 모든 데이터를 보는 구조는 아닌가
- 민감 정보는 필터링되는가
- 접근 로그가 남는가
- 권한 회수가 가능한가

AI에게 외부 도구를 연결할 때 가장 위험한 구조는 “공용 관리자 권한”이다.

모든 사용자의 요청을 AI가 하나의 관리자 계정으로 처리하면, 사용자별 권한 통제가 어렵다.

가능하면 사용자의 권한을 반영해야 한다.

사용자가 볼 수 있는 것만 AI도 볼 수 있다.

이 원칙이 중요하다.

6. 사람 승인 단계가 필요한 이유

AI가 외부 도구를 사용할 때 사람 승인 단계는 매우 중요하다.

특히 쓰기 작업과 실행 작업에서는 필수에 가깝다.

AI가 Jira 이슈를 생성하는 것은 작은 일처럼 보일 수 있다.
하지만 잘못된 이슈가 많이 생성되면 업무 관리가 혼란스러워진다.

AI가 Slack 메시지를 보내는 것도 단순해 보일 수 있다.
하지만 잘못된 알림이 발송되면 다른 팀에 혼란을 줄 수 있다.

AI가 DB 데이터를 수정하거나 배포를 실행하는 것은 훨씬 위험하다.

따라서 다음과 같은 작업은 사람 승인 없이 실행하지 않는 것이 좋다.

- Jira 이슈 생성
- Jira 상태 변경
- PR 댓글 작성
- Slack 공지 발송
- 이메일 발송
- DB 데이터 변경
- 운영 설정 변경
- 배포 실행
- 권한 변경
- 외부 API 상태 변경

사람 승인 단계는 단순히 “확인 버튼” 하나를 추가하는 것이 아니다.

승인 전에 사용자가 무엇을 승인하는지 명확히 볼 수 있어야 한다.

나쁜 승인 방식은 다음과 같다.

AI가 작업을 실행하려고 합니다.
승인하시겠습니까?

이렇게 하면 사용자는 무엇이 실행되는지 알 수 없다.

좋은 승인 방식은 다음과 같다.

AI가 다음 Jira 이슈를 생성하려고 합니다.

프로젝트:
PLATFORM

제목:
관리자 검색 성능 개선 검토

설명:
관리자 메시지 검색에서 contents like 조건 사용 시 부하가 발생할 수 있어
검색 기간 제한 또는 별도 검색 구조를 검토합니다.

라벨:
performance, admin

담당자:
미지정

이 내용으로 생성하시겠습니까?

이렇게 보여줘야 사용자가 판단할 수 있다.

승인 구조에는 다음 정보가 포함되어야 한다.

- 실행할 작업
- 대상 시스템
- 변경될 데이터
- 입력 파라미터
- 예상 결과
- 되돌릴 수 있는지 여부
- 실행자
- 승인자
- 실행 시각

승인과 실행 로그도 남겨야 한다.

그래야 나중에 문제가 생겼을 때 누가 무엇을 승인했고, 어떤 작업이 실행되었는지 확인할 수 있다.

7. 에이전트와 자동화의 차이

AI가 외부 도구를 사용한다는 이야기를 하면 에이전트라는 말이 자주 나온다.

에이전트는 사용자의 목표를 달성하기 위해 여러 단계를 계획하고, 필요한 도구를 사용하며, 결과를 확인하는 AI 구조를 말한다.

예를 들어 단순 자동화는 이런 식이다.

매주 금요일 오후 5시에
이번 주 완료된 Jira 이슈를 조회해서
보고서 초안을 만든다.

이것은 정해진 규칙에 따라 실행된다.

반면 에이전트는 더 유연하다.

사용자:
이번 주 개발팀 진행 상황을 임원 보고용으로 정리해줘.
중요한 리스크가 있으면 같이 표시해줘.

AI 에이전트:
1. 이번 주 완료된 Jira 이슈 조회
2. 진행 중인 주요 이슈 조회
3. 병합된 PR 확인
4. 장애 대응 기록 확인
5. 리스크 후보 정리
6. 임원 보고용 문체로 요약

에이전트는 정해진 하나의 작업만 수행하는 것이 아니라, 목표를 보고 필요한 단계를 구성한다.

하지만 이 유연성이 위험이 될 수 있다.

에이전트가 어떤 도구를 어떤 순서로 사용할지 매번 달라질 수 있기 때문이다.
따라서 에이전트에는 더 강한 통제가 필요하다.

자동화와 에이전트를 비교하면 다음과 같다.

에이전트가 항상 더 좋은 것은 아니다.

정해진 업무는 단순 자동화가 더 안전하고 예측 가능하다.

예를 들어 매일 오전 9시에 특정 리포트를 만드는 작업은 에이전트보다 자동화가 적합하다.

반대로 여러 시스템을 조회해서 상황을 정리해야 하는 작업은 에이전트가 유용할 수 있다.

중요한 것은 업무 성격에 맞게 선택하는 것이다.

8. AI가 문서를 직접 검색할 때 생기는 변화

AI가 문서를 직접 검색할 수 있게 되면 사용 방식이 크게 달라진다.

기존에는 사용자가 문서를 찾아서 AI에게 붙여넣어야 했다.

사용자:
이 문서 내용을 요약해줘.

이 경우 사용자가 먼저 문서를 찾아야 한다.

하지만 AI가 문서 검색 도구를 사용할 수 있다면 이렇게 요청할 수 있다.

사용자:
우리 팀 AI 보안 가이드라인에서
코드 외부 전송 관련 주의사항을 찾아서 요약해줘.

AI는 문서 저장소에서 관련 문서를 검색하고, 필요한 부분을 읽고, 요약할 수 있다.

이 구조는 사내 지식 검색에 매우 유용하다.

- 개발 가이드라인 검색
- 장애 대응 문서 검색
- API 문서 검색
- 회의록 검색
- 정책 문서 검색
- 운영 매뉴얼 검색

하지만 문서 검색 AI에는 중요한 문제가 있다.

첫째, 권한 문제다.

사용자가 볼 수 없는 문서를 AI가 검색해서 답하면 안 된다.

예를 들어 일반 개발자가 인사 문서나 임원 보고서를 볼 수 없어야 한다면, AI도 그 문서를 답변에 사용하면 안 된다.

둘째, 출처 문제다.

AI가 문서를 검색해서 답할 때는 어떤 문서를 근거로 답했는지 보여줘야 한다.

출처가 없으면 사용자는 답변을 검증할 수 없다.

셋째, 최신성 문제다.

사내 문서는 오래된 버전이 남아 있을 수 있다.
AI가 예전 문서를 근거로 답하면 잘못된 안내를 할 수 있다.

따라서 문서 검색 AI에는 다음 기준이 필요하다.

- 사용자 권한에 맞는 문서만 검색
- 답변에 출처 표시
- 최신 문서 우선
- 폐기된 문서 제외
- 문서 버전 표시
- 확실하지 않은 내용은 확인 필요로 표시

AI가 문서를 직접 검색하면 지식 접근성이 좋아진다.
하지만 권한과 출처가 없으면 오히려 위험한 답변이 될 수 있다.

9. AI가 DB를 직접 조회할 때의 위험

AI가 DB를 조회할 수 있으면 강력하다.

예를 들어 다음과 같은 질문이 가능해진다.

최근 1시간 동안 결제 실패가 증가했는지 확인해줘.

어제 신규 가입자 수와 탈퇴자 수를 비교해줘.

특정 API 오류가 발생한 사용자 수를 집계해줘.

AI가 DB 조회 도구를 사용하면 필요한 데이터를 직접 조회할 수 있다.

하지만 DB 연결은 매우 조심해야 한다.

특히 운영 DB를 AI에 직접 연결하는 것은 위험하다.

위험은 여러 가지다.

- 개인정보 조회 위험
- 과도한 쿼리로 인한 DB 부하
- 잘못된 조건의 대량 조회
- SQL Injection 형태의 도구 오용
- 권한 없는 데이터 접근
- AI가 결과를 잘못 해석
- 쓰기 권한이 있을 경우 데이터 변경 위험

AI에게 DB 접근을 허용하려면 최소한 다음 기준이 필요하다.

- 읽기 전용 계정 사용
- 운영 DB 직접 연결 지양
- 복제 DB 또는 분석 DB 사용
- 조회 가능한 테이블 제한
- 개인정보 컬럼 마스킹
- 최대 조회 건수 제한
- 쿼리 timeout 설정
- 대량 쿼리 차단
- 모든 조회 로그 기록
- 사용자별 권한 반영

가장 안전한 방식은 AI가 직접 SQL을 자유롭게 실행하지 못하게 하는 것이다.

대신 미리 정의된 조회 도구를 제공하는 방식이 좋다.

예를 들어 다음과 같은 도구를 만들 수 있다.

getPaymentFailureCount(startTime, endTime)

getSignupStats(date)

getApiErrorRate(apiName, startTime, endTime)

AI는 이 도구를 호출할 수 있지만, 직접 임의의 SQL을 작성하지는 못한다.

이렇게 하면 위험을 줄일 수 있다.

AI에게 DB를 연결할 때는 편의성보다 안전성이 먼저다.

10. AI가 API를 직접 호출할 때의 위험

AI가 사내 API나 외부 API를 호출할 수도 있다.

예를 들어 다음과 같은 요청이 가능하다.

이 사용자에게 테스트 알림을 보내줘.

이 Jira 이슈를 진행 중으로 변경해줘.

이 배포 작업을 시작해줘.

이 외부 업체 API 상태를 확인해줘.

API 호출은 읽기와 쓰기가 섞여 있다.

상태 조회 API는 읽기 작업이다.

GET /deployments/status

하지만 상태 변경 API는 쓰기 작업이다.

POST /deployments/start

POST /users/block

POST /payments/cancel

AI가 API를 호출할 때는 이 차이를 명확히 해야 한다.

읽기 API는 권한과 로그를 관리하면서 사용할 수 있다.
하지만 쓰기 API는 반드시 승인 구조가 필요하다.

특히 다음 API는 AI가 단독으로 호출하면 안 된다.

- 결제 승인
- 결제 취소
- 포인트 지급
- 포인트 차감
- 사용자 차단
- 관리자 권한 변경
- 데이터 삭제
- 배포 실행
- 외부 업체 상태 변경
- 대량 메시지 발송

AI가 API를 호출하는 구조에서는 API 자체도 안전해야 한다.

AI가 잘못된 파라미터를 보내도 API가 검증해야 한다.

예를 들어 사용자 차단 API라면 다음을 검증해야 한다.

- 호출자가 관리자 권한을 가지고 있는가
- 대상 사용자가 존재하는가
- 자기 자신을 차단하려는 것은 아닌가
- 이미 차단된 사용자인가
- 차단 사유가 있는가
- 감사 로그가 남는가
- 대량 차단 요청은 제한되는가

AI가 호출한다고 해서 API 검증을 생략하면 안 된다.

오히려 AI가 호출할 수 있는 API일수록 더 강하게 검증해야 한다.

11. 도구 호출 결과를 검증해야 하는 이유

AI가 외부 도구를 호출하면 결과를 받는다.

문제는 AI가 그 결과를 항상 정확히 해석하는 것은 아니라는 점이다.

예를 들어 DB 조회 결과가 다음과 같다고 해보자.

AI는 이를 보고 “실패율은 약 1.5%입니다”라고 말할 수 있다.

이 계산은 맞다.

하지만 실무에서는 추가 확인이 필요할 수 있다.

- 평소 실패율은 얼마인가
- 특정 PG사에 집중되어 있는가
- 특정 시간대에 몰려 있는가
- 같은 사용자의 반복 실패인가
- 배포 이후 증가했는가
- 외부 업체 장애 공지가 있었는가

도구 결과를 단순히 요약하는 것과, 운영적으로 해석하는 것은 다르다.

또 AI가 숫자를 잘못 계산할 수도 있다.
도구 결과에 없는 내용을 추측할 수도 있다.
컬럼 의미를 잘못 이해할 수도 있다.

따라서 중요한 작업에서는 AI의 해석을 검증해야 한다.

검증 방법은 다음과 같다.

- 원본 결과를 함께 표시
- 계산식 표시
- 기준 기간 명시
- 비교 대상 표시
- 확정과 추정을 구분
- 출처 표시
- 사람이 재확인할 항목 표시

예를 들어 좋은 답변은 다음과 같다.

최근 1시간 결제 요청 10,000건 중 실패 150건으로 실패율은 1.5%입니다.

계산:
150 / 10,000 * 100 = 1.5%

확인 필요:
- 평소 같은 시간대 실패율과 비교 필요
- PG사별 실패율 분리 필요
- 최근 배포 이후 증가 여부 확인 필요

이렇게 답하면 사용자가 판단하기 쉽다.

AI가 도구 결과를 사용할 때는 결론만 말하는 것보다, 근거와 확인 필요 항목을 함께 보여주는 것이 좋다.

12. 도구 사용 AI의 로그와 감사 추적

AI가 외부 도구를 사용하면 로그가 중요해진다.

단순 챗봇 답변은 틀리더라도 대화 기록을 보면 된다.
하지만 도구 호출은 실제 시스템과 연결된다.

따라서 다음 기록이 남아야 한다.

- 누가 요청했는가
- 언제 요청했는가
- 어떤 AI가 처리했는가
- 어떤 도구를 호출했는가
- 어떤 파라미터를 사용했는가
- 어떤 결과가 반환되었는가
- 사용자가 승인했는가
- 실제 실행되었는가
- 실패했는가
- 결과가 어디에 반영되었는가

예를 들어 AI가 Jira 이슈를 생성했다면 다음 기록이 필요하다.

요청자:
hong@example.com

승인자:
kim@example.com

도구:
createJiraIssue

프로젝트:
PLATFORM

제목:
관리자 검색 성능 개선 검토

실행 시각:
2026-05-09 14:32:10

결과:
PLATFORM-123 생성 완료

이런 로그가 있어야 나중에 추적할 수 있다.

특히 다음 작업은 감사 로그가 필수다.

- 권한 변경
- 관리자 기능 실행
- 데이터 수정
- 데이터 삭제
- 외부 API 쓰기 호출
- 배포 관련 작업
- 결제와 정산 관련 작업

감사 로그는 단순 디버깅용 로그와 다르다.

디버깅 로그는 문제를 해결하기 위한 기술 로그다.
감사 로그는 누가 어떤 중요한 작업을 했는지 추적하기 위한 기록이다.

AI가 도구를 사용하는 구조에서는 감사 로그가 더 중요해진다.

왜냐하면 사람이 직접 버튼을 누른 것이 아니라, AI가 중간에서 작업을 구성할 수 있기 때문이다.

13. 사용자가 볼 수 없는 데이터 차단

도구 사용 AI에서 반드시 지켜야 하는 원칙이 있다.

사용자가 볼 수 없는 데이터는 AI도 답변에 사용하면 안 된다.

예를 들어 일반 개발자가 볼 수 없는 문서가 있다고 하자.

- 인사 문서
- 임원 보고서
- 민감한 보안 감사 문서
- 다른 팀의 비공개 장애 보고서
- 개인정보 원본 데이터

AI가 이런 문서를 검색해서 답변에 사용하면 권한 우회가 된다.

사용자는 직접 문서를 볼 수 없는데, AI를 통해 내용을 알 수 있기 때문이다.

이 문제는 생각보다 자주 발생할 수 있다.

AI 도구가 관리자 권한으로 문서 저장소를 검색하고, 그 결과를 사용자에게 요약해주면 권한이 깨진다.

따라서 도구 사용 AI는 사용자 권한을 반영해야 한다.

사용자 A가 볼 수 있는 문서만 AI가 검색한다.
사용자 A가 접근 가능한 Jira 프로젝트만 AI가 조회한다.
사용자 A가 볼 수 있는 GitHub 저장소만 AI가 분석한다.
사용자 A에게 허용된 API만 AI가 호출한다.

이 구조를 만들기 어렵다면, 최소한 도구별 접근 범위를 제한해야 한다.

예를 들어 개발팀 AI는 개발팀 문서만 검색하고, 인사나 재무 문서는 검색하지 못하게 해야 한다.

권한 차단은 답변 단계에서만 하면 안 된다.

검색 단계에서부터 막아야 한다.

나쁜 방식은 다음과 같다.

AI가 모든 문서를 검색한다.
→ 답변할 때 민감한 내용을 숨긴다.

좋은 방식은 다음과 같다.

처음부터 사용자가 접근 가능한 문서만 검색한다.
→ 그 결과만 AI에게 전달한다.

AI에게 민감한 데이터를 보여준 뒤 “답변하지 마”라고 하는 것은 안전하지 않다.

민감한 데이터는 애초에 AI 입력으로 들어가지 않게 하는 것이 더 안전하다.

14. 도구 사용 AI를 설계할 때의 기본 원칙

AI가 외부 도구를 사용하도록 설계할 때는 몇 가지 기본 원칙이 필요하다.

첫째, 읽기부터 시작한다.

처음부터 쓰기 작업을 연결하지 않는다.

문서 검색, Jira 조회, PR 요약, 로그 조회 같은 읽기 작업부터 시작하는 것이 안전하다.

둘째, 권한을 최소화한다.

AI에게 관리자 권한을 주지 않는다.
필요한 시스템, 필요한 데이터, 필요한 기능만 허용한다.

셋째, 쓰기 작업에는 승인 단계를 둔다.

AI가 생성한 내용을 사용자가 확인한 뒤 실행해야 한다.

넷째, 실행 결과를 기록한다.

도구 호출 로그와 감사 로그를 남겨야 한다.

다섯째, 민감 정보를 필터링한다.

개인정보, 인증키, 토큰, 비밀번호, 운영 비밀 정보는 AI 입력으로 들어가지 않게 해야 한다.

여섯째, 도구 결과의 출처를 표시한다.

문서 검색 결과나 DB 조회 결과를 바탕으로 답변할 때는 근거를 확인할 수 있어야 한다.

일곱째, 실패 시 안전하게 중단한다.

도구 호출이 실패했는데 AI가 추측으로 답하면 안 된다.

예를 들어 Jira 조회가 실패했다면 이렇게 말해야 한다.

Jira 이슈 조회에 실패했습니다.
현재 정보만으로는 이번 주 완료 이슈를 확정할 수 없습니다.

실패했는데도 그럴듯하게 답하는 것은 위험하다.

여덟째, 고위험 작업은 AI 단독 실행을 금지한다.

배포, DB 수정, 권한 변경, 결제·정산 관련 작업은 반드시 사람 승인과 별도 검증이 필요하다.

15. MCP로 넘어가기 전에 알아야 할 개념

다음 장부터는 MCP를 다룬다.

MCP는 Model Context Protocol의 줄임말이다.
AI가 외부 도구와 더 표준화된 방식으로 연결될 수 있도록 만든 프로토콜이다.

MCP를 이해하기 전에 이번 장의 개념을 정리해두는 것이 중요하다.

MCP는 갑자기 등장한 새로운 마법 같은 기술이 아니다.

그 배경에는 다음 문제가 있다.

AI가 문서를 읽고 싶다.
AI가 파일을 검색하고 싶다.
AI가 DB를 조회하고 싶다.
AI가 Jira나 GitHub 같은 업무 도구를 사용하고 싶다.
그런데 도구마다 연결 방식이 다르다.
권한과 보안도 제각각이다.
AI 도구마다 플러그인 방식도 다르다.

이 문제를 해결하려면 AI와 외부 도구 사이에 표준적인 연결 방식이 필요하다.

MCP는 이런 요구에서 등장한 개념이다.

MCP를 이해하려면 다음 개념을 알고 있어야 한다.

- AI는 외부 도구를 호출할 수 있다
- 도구에는 읽기 작업과 쓰기 작업이 있다
- 읽기보다 쓰기가 더 위험하다
- 도구 호출에는 권한이 필요하다
- 사용자가 볼 수 없는 데이터는 AI도 볼 수 없어야 한다
- 중요한 실행에는 사람 승인 단계가 필요하다
- 모든 도구 호출은 로그로 남아야 한다
- 에이전트는 여러 도구를 조합할 수 있다
- 자동화와 에이전트는 다르다

이 개념이 잡혀 있어야 MCP를 안전하게 이해할 수 있다.

MCP는 도구 연결을 편하게 해준다.
하지만 보안과 권한 문제를 자동으로 해결해주지는 않는다.

도구를 연결하기 쉬워질수록, 어떤 도구를 어떤 권한으로 연결할지 더 신중해야 한다.

16. 실무 예시: 문서 검색 AI에서 업무 실행 AI로 확장하기

실무에서 가장 안전한 시작점은 문서 검색 AI다.

예를 들어 개발팀 문서 저장소에 다음 문서들이 있다고 해보자.

- API 개발 가이드
- 장애 대응 매뉴얼
- AI 보안 가이드라인
- PR 리뷰 기준
- 배포 체크리스트

처음에는 AI가 이 문서를 검색하고 답변하게 할 수 있다.

사용자:
관리자 API 개발 시 감사 로그를 남겨야 하는 기준을 찾아줘.

AI:
AI가 문서 검색 도구를 사용한다.
관련 가이드라인을 찾는다.
감사 로그 기준을 요약한다.
출처 문서를 표시한다.

이 단계는 읽기 중심이다.

다음 단계에서는 Jira와 연결할 수 있다.

사용자:
이 감사 로그 누락 건을 Jira 이슈 초안으로 만들어줘.

AI:
문서 기준을 바탕으로 이슈 초안을 만든다.
사용자가 확인한다.
승인하면 Jira에 등록한다.

여기서부터는 쓰기 작업이 포함된다.

따라서 사람 승인 단계가 필요하다.

더 나아가 GitHub와 연결할 수도 있다.

사용자:
이 이슈와 관련된 최근 PR을 찾아줘.

AI:
GitHub PR을 검색한다.
관련 변경 사항을 요약한다.
감사 로그 누락 가능성이 있는 파일을 정리한다.

이 단계는 다시 읽기 중심이다.

마지막으로 AI가 PR 댓글까지 작성하게 할 수 있다.

사용자:
이 내용을 PR에 코멘트로 남겨줘.

AI:
코멘트 초안을 보여준다.
사용자가 승인한다.
승인 후 PR 댓글을 등록한다.

이 흐름에서 중요한 것은 단계별로 위험도가 달라진다는 점이다.

문서 검색:
읽기 작업

Jira 이슈 초안:
생성 전까지는 낮은 위험

Jira 이슈 등록:
쓰기 작업, 승인 필요

GitHub PR 검색:
읽기 작업

PR 댓글 등록:
쓰기 작업, 승인 필요

처음부터 모든 것을 연결하면 위험하다.

읽기 중심으로 시작하고, 쓰기 작업은 승인 구조를 붙여 확장하는 것이 안전하다.

17. 정리

AI가 외부 도구를 사용할 수 있게 되면 AI의 역할은 크게 달라진다.

단순 챗봇은 사용자의 질문에 답변한다.
도구 사용 AI는 문서, DB, API, Jira, GitHub, Slack 같은 외부 시스템을 사용해 필요한 정보를 찾고 작업을 보조한다.

이 구조는 매우 강력하다.

하지만 그만큼 권한, 보안, 승인, 로그가 중요해진다.

AI가 외부 도구를 사용할 때는 다음 원칙을 지켜야 한다.

- 단순 답변과 도구 실행을 구분한다
- 읽기 작업과 쓰기 작업을 분리한다
- 처음에는 읽기 도구부터 연결한다
- 쓰기 작업에는 사람 승인 단계를 둔다
- 사용자가 볼 수 없는 데이터는 AI도 볼 수 없게 한다
- AI에게 관리자 권한을 무분별하게 주지 않는다
- 도구 호출 기록과 감사 로그를 남긴다
- DB와 운영 API 연결은 강하게 제한한다
- AI가 도구 결과를 잘못 해석할 수 있음을 전제로 검증한다
- 고위험 작업은 AI 단독 실행을 금지한다

AI가 외부 도구를 사용한다는 것은 단순히 편리한 기능을 추가하는 일이 아니다.

AI에게 회사 시스템의 일부를 맡기는 일이다.

따라서 기술적으로 연결하는 것보다 더 중요한 것은 통제 구조를 설계하는 것이다.

다음 장에서는 이런 외부 도구 연결을 표준화하려는 흐름인 MCP가 왜 등장했는지 살펴본다.

32장 핵심 요약